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BACKGROUND OF THE INVENTION 

The present invention relates to an apparatus 
and method for allocating resources of a computer 
system to users. More particularly, the invention 
5 relates to an apparatus and method for allocating 
computer resources of a system constituted of a 
plurality of computers interconnected by a network, the 
apparatus and method being capable of allocating 
computer resources in real time, the computer resources 

10 being necessary for maintaining a service level 

contracted beforehand with each user while a plurality 
of user's requests are processed, and capable of 
guaranteeing securities between users. 

Business types are increasing which outsource 

15 intra- company information system running and company 
home page management to an ASP (application service 
provider) in order to reduce the cost of an information 
department. Many ASP's outsource supply, running and 
management of computer resources to a data center. 

20 The data center prepares a plurality of 

computer resources and allocates them to a plurality of 
user companies in order to reduce the running cost of 
the data center itself and supply low price services to 
the user companies. In order to guarantee securities 

25 between user companies, generally the data center often 



allocates different computer resources and storage 
resources to each user company. 

A user company load fluctuates between time 
zones, seasons and the like. From this reason, the 
5 data center often contracts with a user company so as 
to increase or decrease allocated resources in 
accordance with the user company load. The company 
load, particularly the load of the company whose home 
page management is outsourced, is difficult to predict 

10 because many and unidentified consumers access the home 
page via the Internet. In order to deal with this, a 
user company contracts with a data center under the 
contract term that a predetermined number of computer 
resources are increased during a predetermined period 

15 by predicting on the user company side an increase in 
the load to be caused by a new product announcement. 
The data center allocates the increased computer 
resources to other user companies during the other 
period to efficiently utilize the resources. In order 

20 to facilitate such a configuration change, the data 
center is configured in such a manner that a load 
allocating apparatus is installed at the front stage of 
a plurality of computer resources to allocate the 
computer resources to a user company A during some 

25 period and some computer resources to a user company B 
during the other period. An example of the load 
allocating apparatus is an ACE director of Alteon 
WebSystems. A load allocating apparatus is disclosed, 



for example, in Nikkei Open Systems, 1999, 12, No. 81, 
pp. 128 - 131. Settings of a load allocating 
apparatus, for example, the number of allocated 
servers, is manually made by the data center in 
5 accordance with a contract with a user company, such as 
the contract described above. If it is necessary to 
increase storage resources, it is necessary to perform 
mirroring of the contents of storages. 

Since a data center provides different 

10 computer resources to each of a number of user 
companies, the management cost for the number of 
computer resources increases. In order to avoid this, 
it is conceivable that a small number of computer 
resources each having a high performance, e.g., highly 

15 multiplexed computers SMP, are introduced and a 

plurality of user companies share them. In order to 
guarantee securities between user companies, a virtual 
computer function is utilized. An example of the 
virtual computer is a Processor Resource Management 

20 Feature PRMF of Hitach Ltd. PRMF is disclosed, for 

example, in the HIT AC manual 8080-2-148-60. According 
to PRMF, a plurality of operating systems (OSes) run on 
one computer, and independent resources such as main 
storages and network adapters are allocated to each OS. 

25 Since resources are not shared among OSes, securities 
are guaranteed between programs of different user 
companies executed on different OSes. Although PRMF is 
configured so that ratios of CPU resources allocated to 



OSes can be controlled, a ratio change is limited only 
to those ratios planned beforehand. 

It is becoming usual to make a service level 
contract between and ASP's and ISP's (Internet service 
provider) and user companies. A user makes a contract 
with ASP to guarantee a service level such as 
connectivity, availability and latency performance. In 
addition to this contract, a compensation contract for 
the case that the guarantee level is not realized is 
often made. 

U.S. Patent No. 5,774,668 discloses that a 
data center having a plurality of application servers 
monitors the load of each service application and 
increases or decreases the number of application 
servers in accordance with a change in the load. 
However, in U.S. Patent No. 5,774,668, a process load 
of each user (client) is not monitored. Further, U.S. 
Patent No. 5,774,668 does not teach that the data 
center increases or decreases the number of application 
servers in order to maintain the service level 
contracted with each user (client) . 

With the manual setting of a load allocating 
apparatus by a data center based on the contract with a 
user company, it is difficult to deal with in real time 
an abrupt load change not predicted by the user 
company. This is also applied to the case that 
different computers are allocated to each user company 
or that a virtual computer is used. It is difficult to 



increase storage resources rapidly because of an 
overhead of data copy for mirroring. In the case of a 
data center, the latency performance and the like are 
difficult to be defined and measured if the process 
contents are not stereotyped, e.g., if a process 
request from one user company is processed by a 
plurality of computers. 

SUMMARY OF THE INVENTION 

In order to solve the above-described 
problems, an object of the invention is to provide a 
resource allocating apparatus and method for 
allocating, dynamically or in real time, computer 
resources and storage resources of a data center to 
each user company in response to a load change of each 
user company. 

To this end, according to the invention, a 
user identification table is prepared for each service 
level contract made between each user company and the 
data center, this table storing information on a 
correspondence between a unique user ID and a user 
company. A related user company is identified from a 
user request packet sent to the data center. The 
packet is added with the user ID corresponding to the 
service level contracted with the user company. A 
management server forms a definition table for defining 
a group of computers which processes the user request 
belonging to each user ID, and dynamically sets the 



definition table to the load allocating apparatus. The 
load allocating apparatus selects a computer group from 
groups set to the definition table to make it execute 
the user request. If there is a plurality of load 
5 allocating apparatus, the management server controls to 
maintain integrity of the definition table between load 
allocating apparatus. 

Furthermore, the management server monitors 
the operation state of each computer to check whether 

10 the service level contract with each user company is 
satisfied or not, and if necessary increases or 
decreases computer resources. Specifically, the 
management server changes a computer group in the 
definition table and sets it again to the load 

15 allocating apparatus. 

Still further, the management server forms a 
history of information on whether the computer resource 
amount and service level contract corresponding to each 
user ID are satisfied, to thereafter form charge 

20 information. In order to measure the process 

throughput of the whole data center, the number of user 
requests and responses transmitted to and from the data 
center may be measured for each user ID. 

According to another embodiment of the 

25 invention, the data center is structured by using 

computers having a virtual computer mechanism. Each 
user company is provided with a virtual computer 
mechanism under the control of one OS, and the 



management server dynamically sets a use allocation 
rate of CPU of each computer mechanism, to each 
computer. The management service monitors the 
operation state of each computer to check whether the 
service level contract is satisfied, and if necessary 
increases or decreases the use allocation rate of CPU. 

According to the invention, each user company 
is provided with a user ID for identifying the 
contracted service level, and in accordance with the 
user ID, computer resources are supplied. In 
accordance with the monitoring result of the operation 
state of each computer, the computer resource amount 
can be automatically increased or decreased through 
comparison between the monitoring result and the 
service level contract corresponding to each user ID. 
In this manner, a computer resource allocation can be 
changed in real time even for a rapid load change not 
predicted on the user company side. 

In the embodiments of the invention, although 
a juridical corporation is used by way of example as a 
user making a service level contract with the data 
center, the invention is also applicable to a private 
user depending upon conditions. Therefore, in the 
specification, a user company is often described simply 
as a user. 

Even if a computer resource allocation is 
changed, storage resources are shared by all computers 
and the storage side checks an access privilege from 
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the user ID. Therefore, securities between users can 
be guaranteed without an overhead of mirroring. 

Further, the numbers of requests and 
responses per unit time passing through the data center 
5 are measured and collected for each user ID. It is 
therefore easy to measure the performance of the data 
center as viewed from users. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a diagram showing an example of the 
10 structure of a system constituted of a data center and 
users interconnected by the Internet. 

Fig. 2 is a diagram showing an example of the 
structure of a data center. 

Fig. 3 is a diagram showing the structure of 
15 a gateway shown in Fig. 2. 

Fig. 4 a diagram showing the structure of a 
management server shown in Fig. 2. 

Figs. 5(A) to 5(C) are diagrams showing 
examples of tables possessed by a load allocating 
20 apparatus shown in Fig. 2. 

Fig. 6 is a diagram showing an example of a 
table possessed by a storage shown in Fig. 2. 

Figs. 7(A) to 7(0) are diagrams showing the 
structures of packets passing through signal lines 
2 5 shown in Fig. 2. 

Fig. 8 is a flow chart illustrating an 
example of an ordinary operation of a control program 
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shown in Fig. 4. 

Figs. 9(A) and 9(B) are block diagrams 
showing another example of an ordinary operation flow 
of the control program shown in Fig. 4. 
5 Fig. 10 is a diagram showing another example 

of the structure of the data center. 

Fig. 11 is a diagram showing data stored in 
LPAR control registers shown in Fig. 10. 

Figs. 12(A) to 12(0) are diagrams showing the 
10 structures of packets passing through signal lines 
shown in Fig. 10. 

Fig. 13 is a diagram showing the structure of 
a management server shown in Fig. 10. 

Fig. 14 is a flow chart illustrating an 
15 example of the ordinary operation of a control program 
shown in Fig. 13. 

Fig. 15 is a diagram showing another example 
of the structure of the data center. 

Figs. 16(A), 16(C), 16(D), 16(M) and 16(0) 
20 are diagrams showing the structures of packets passing 
through signal lines shown in Fig. 15. 

Fig. 17 is a diagram showing the structure of 
a gateway shown in Fig. 15. 

Fig. 18 is a diagram showing the structure of 
2 5 a management server shown in Fig. 15. 

Fig. 19 is a flow chart illustrating an 
example of the operation of a control program shown in 
Fig. 18. 
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Fig. 20 is a flow chart illustrating an 
example of an initial operation of the control program 
shown in Fig. 4. 

Fig. 21 is a flow chart illustrating an 
5 example of an initial operation of a control program 
shown in Fig. 13. 

Fig. 22 is a diagram showing a condition 
input dialog for a user using the data center shown in 
Fig. 2. 

10 Fig. 23 is a diagram showing a service level 

condition input dialog for a user using the data center 
shown in Fig. 2. 

Fig. 24 is a diagram showing a service level 
condition input dialog for a user using the data center 
15 shown in Fig. 9. 

Fig. 25 is a diagram showing a condition 
input dialog for a user using the data center shown in 
Fig. 15. 



DESCRIPTION OF THE EMBODIMENTS 

2 0 Embodiments of the invention will be 

described with reference to the accompanying drawings. 

A first embodiment is shown in Fig. 1. In 
the example shown in Fig. 1, a data center as the main 
subject of this invention is connected via the Internet 

25 110 to a user company A (AA0) , a user company B (BB0) 

and consumers cO and cl accessing the home pages of the 
A and B companies. Clients aO, al and a2 have private 



network addresses (PNA) of an A company system and 
access a gateway DO in the data center via gateways AO 
and Al and a virtual private network (VPN) . Requests 
from the clients cO and cl will be later described in a 
5 third embodiment. 

Fig. 2 shows the structure of a data center 
DDO. In this example, the data center has a three- 
layer structure including a Web server group, an AP 
server group and a DB server group. The Web server 

10 provides a Web browser interface in response to a user 
request. The AP server runs an application program 
which is generated from a Web server. The DB server 
deals with a database access request issued from an 
application program. 

15 Fig. 22 shows an example of an input dialog 

to be used when the user company A makes a use 
condition contract with the data center. In this 
example, the contents of this contract are as follows. 
AO or Al is used as the access request source IP 

20 address of a request packet in order to identify that 
an access request input to the gateway DO is an access 
request from a user belonging to the user company A. 
In addition, the user company A can use all of the Web 
server group, AP server group and DB server group of 

25 the data center, and a program set up in response to a 
user request of the user company A uses alOO as the IP 
address of a Web server, a200 as the IP address of an 
AP server and a300 as the IP address of a DB server. 
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Fig. 23 shows an example of an input dialog 
to be used when the user company A makes a service 
level contract with the data center. In this example, 
at least two Web servers, two AP servers and two DB 
5 servers are allocated to the user company A, and all 
the servers are made to run at a CPU operation rate 
smaller than 50 %. If the operation rate becomes 50% 
or higher, eight servers at a maximum are allocated, 
i.e., eight Web servers, eight AP servers and eight DB 
m9 10 servers. In this example, although check symbols are 

'C not entered in the input dialog, an output transaction 

43 throughput, for example, at an output of the data 

=j3 center, a throughput ratio of an output transaction to 

Q an input transaction, and a transaction process latency 

□ 15 may be entered in the service level contract. 

Q It is assumed that in accordance with the 

contract made by the input dialog, Web servers alO and 
all, AP servers a20 and a21 and DB servers a30 and a31 
are allocated to the A company, and Web servers blO and 
20 bll, AP servers b20 and b21 and DB servers b30 and b31 
are allocated to the B company, respectively as initial 
values. A storage SO is allocated to the A and B 
companies in the unit of a volume. A volume V0 is 
allocated to the A company and a volume VI is allocated 
25 to the B company. Storages SI and S2 are allocated in 
the similar manner, although this allocation is not 
shown in Fig. 2. Servers ylO to y31 are reserved 
servers which are allocated when the loads of the A and 
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B companies become large. 

It is assumed that the IP addresses used by 
the A company are alOO for the Web servers, a200 for 
the AP servers, and a300 for the DB servers. 
5 Similarly, it is assumed that by using the input 

dialog, the IP addresses used by the B company are set 
to blOO for the Web servers, b200 for the AP servers, 
and b300 for the DB servers. 

With reference to the relevant drawings, the 

10 description is given as to how the gateways AO and DO, 
management server CO and load allocating apparatus 
dlOO, d200 and d300 deal with a request from the user A 
by using the servers alO to a31. 

The structure of a request packet which the 

15 client aO sends to the gateway AO shown in Fig. 1 is 
shown in Fig. 7(A) at 1200. A start field (alOO) of 
the packet corresponds to the address of a destination 
server, and the next field (aO) corresponds to the 
address of a source client. When the packet 1200 is 

20 sent to the Internet 110, the gateway AO capsulizes the 
packet for a virtual private network (VPN) to form a 
packet 1201 shown in Fig. 7 (A) . The gateway DO 
uncapsulizes this packet to obtain the packet 1200. 
Since this technology is well known, the detailed 

25 description thereof is omitted. 

Fig. 3 is a diagram showing the structure of 
the gateway DO at the input of the data center DD0. 
The gateway DO uncapsulizes the packet shown in Fig. 



7 (B) input from a signal line 10, obtains a user ID #0 
by referring to a user ID table T10, and. adds #0 to the 
packet to generate a packet 1202 shown in Fig. 7 (C) and 
send it to a signal line L10. The user ID table T10 is 
5 formed by the management server CO in accordance with 
the user condition input dialog shown in Fig. 22 and 
set beforehand to the gateway DO via a signal line L0. 
Namely, the request which accessed the data center DDO 
by using the source address AO or Al is regarded as the 

10 request from the user having the user ID #0, i.e., the 
request from the A user. 

At the same time when the packet 1202 is 
generated, a counter circuit 1003 of the gateway DO 
counts a pass of the input request having the user ID 

15 #0 and a count result is set to an input/output result 
storage table Til. 

The load allocating apparatus dlOO which 
received the packet 1202 via the signal line L10 has a 
server address correspondence table T3 0 shown in Fig. 

20 5(A). This table T30 stores, for each user ID, 
information on to which real server a request to 
servers, which was input in the dialog shown in Fig. 22 
as a user application, is sent. Since the packet 1202 
has the user ID #0 and the destination address alOO, 

25 the load allocating apparatus dlOO changes the 

destination server address alOO to either alO or all by 
referring to the table T30, and generates a packet 1203 
shown in Fig. 7 (D) . This technology of selecting and 



changing the destination address is well known, and so 
the detailed description thereof is omitted. 

The Web server alO receives the packet 1203, 
and if a process at an AP server is necessary, 
5 generates a packet 1204 (Fig. 7(E)) for requesting an 
access to a200. This packet 1204 is sent via a bus 
LI 10 to a load allocating apparatus d200. The load 
allocating apparatus d200 has a server address 
correspondence table T31 shown in Fig. 5(B). By 
10 referring to this table, the load allocating apparatus 
d200 changes the destination server address a200, for 
example, to a20 to generate a packet 1205 (Fig. 7(F)). 

Similarly, the AP server a20 generates, if 
necessary, a packet 1206 (Fig. 7(G)), and a load 
15 allocating apparatus d300 having a server address 

correspondence table T32 (Fig. 5(C)) changes the packet 
1206 to a packet 1207 (Fig. 7(H)) to make the DB server 
a30 process this packet. 

A response from the DB server a30 to the AP 
20 server a20, Web server alO, and to client aO is 

returned in a manner similar to that described above. 
In this case, packets 1208 (Fig. 7(1)) to 1214 (Fig. 
7(0)) are sequentially generated. When the gateway DO 
sends the response packet 1213 (Fig. 7 (N) ) to the 
25 gateway AO, the counter circuit 1003 of the gateway DO 
counts a pass of the output request having the user ID 
#0 and a count result is set to the input/output result 
storage table Til. 
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Although not described above, when a request 
is issued from the user company B, the gateway DO adds 
a user ID #1 to the packet in the similar manner to 
that described above, and the packet is sequentially 
5 processed by the servers blO to b31 in the similar 
manner to that described above. 

With the above operations, the servers for 
executing the processes of the users A and B are 
divided into or allocated as the servers alO to a31 and 

10 the servers blO to b31. 

Access to the storage will be described by 
taking as an example the storage SO shown in Fig. 2. 
The storage SO is shared by all Web servers by a signal 
line L120. When each server accesses the storage, the 

15 user ID is added to the access request. The storage SO 
has a volume access privilege table T33 shown in Fig. 
6. This table T33 stores, for each user ID, 
information on which volume is permitted to access. If 
the access request of the user ID #1 is an access to 

20 the volume V0, the storage SO refers to this table T33 
and rejects this access. Therefore, even if the 
storage SI is shared by all Web servers, securities 
between the users A and B can be guaranteed. 

Referring to Fig. 2, the management server CO 

25 monitors the operation states of the servers and load 
allocating apparatus via signal lines L100, L200 and 
L300. The monitoring contents are determined from the 
contents of the service level contract with each user 
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and the function of a monitoring program. For example 
the monitoring contents include a CPU operation rate, 
load allocating destination history and the like. The 
monitoring program may run on the management server CO 
each server or each load allocating apparatus. The 
management server CO acquires the contents of the 
input/output result table Til of each user from the 
gateway DO via the signal line LO. 

Fig. 4 is a diagram showing the structure of 
the management server CO. T19 represents a user ID 
table which is set by a control program P20 by using 
the user condition input dialog shown in Fig. 22. T20 
represents a service level contract content table for 
each user, which table is set by the control program 
P20 by using the service level condition input dialog 
shown in Fig. 23. In this contract, the user having 
the user ID #0 is allocated with at least two Web 
servers, two AP servers and two DB servers, all these 
servers run a program at a CPU operation rate smaller 
than 50 %, and if the CPU operation rate exceeds this 
level, the number of servers is increased to eight 
servers at each server group at the maximum. In the 
contract with the user having the user ID #1, the user 
is allocated with at least two Web servers, two AP 
servers and two DB servers, the access response 
throughput of the data center is maintained 30 
responses per second, and if the throughput lowers thi 
level, the number of servers is increased to six 
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servers at each server group at the maximum. 

With reference to the monitoring results and 
the service level contract content table T20, the 
control program P20 checks whether the current resource 
5 allocation satisfies the service level contract, and 
stores the check results in a service history storage 
table T21. For example, CPU operation rate history of 
all servers allocated to the user ID #0 is recorded in 
the service history storage table T21. If the 
10 monitoring result does not satisfy the service 

contract, the control program P20 increases the number 
of servers to be allocated. To this end, the 
management server is provided with a server allocation 
management table T22 and a server address 
15 correspondence table T23. The server management table 
T22 stores information on which server is allocated to 
which user. The server address correspondence table 
T23 is a correspondence table storing information on a 
correspondence between the server name recognized by a 
20 user application and an allocated real server. This 
table T23 is a master table of server address 
correspondence tables T30 to T32 possessed by the load 
allocating apparatus dlOO to d300. The server history 
storage table also stores charge information. Although 
25 not shown, if the contract with the user states that 
the charge is increased in accordance with the number 
of allocated servers, the charge calculation equation 
changes so that the changed equation is reflected. If 



the contract with the user states that the charge is 
changed in accordance with the degree of not 
maintaining the contracted service level, then this 
change is reflected. 
5 The procedure of the control program P2 0 of 

the management server CO to initially allocate 
resources in order to execute the above-described 
control will be described with reference to Fig. 20. 

The management server CO which executes the 

o 

10 control program P20 first acquires the information 

133. 

yB entered in the user condition input dialog shown in 

=0 Fig. 22 to generate the user ID table T19 (Step 1901) . 

IV 

=0 Next, this information is set to the gateway DO via the 

p signal line L0 (Step 1902) . 

Q 15 The management server CO acquires the 

p information entered in the service level condition 

input dialog shown in Fig. 23 to generate the service 
level contract content table T2 0 and the virtual 
address field in the service address correspondence 
20 table T23 (Step 1903) . Next, servers are allocated 
from each of the Web server, AP server and DB server 
groups. Specifically, after confirming that each user 
is allocated with at least two servers of each group, 
by referring to the service level contract content 
25 table T20, the management server CO generates the 
server allocation management table T22 and the real 
address field of the server address correspondence 
table T23 (Step 1904) . Next, a necessary portion of 



the generated server address correspondence table T23 
is copied to the load allocation apparatus dlOO, d200 
and d300 via the signal lines L100, L200 and L300 (Step 
1905) . 

5 With reference to the service level contract 

content table T23, the service history storage table 
T21 is generated (Step 1906) . Specifically, a field 
for recording the CPU operation rate history is 
• generated for the user ID #0 and a field for recording 
10 a transaction output throughput history (not shown) is 
generated for the user ID #1. 

With the above operations, information 
necessary for the resource allocation control is 
prepared and set to the gateway DO and the load 
15 allocating apparatus dlOO, d200 and d300, so that the 
system can start its operation under the conditions of 
proper resource allocation. 

Next, the procedure of the control program 
P20 to change a resource allocation when the load 
20 increases will be described with reference to Fig. 8. 

As described earlier, the operation 
information of the system is monitored via the signal 
lines L100, L200, L300 and L0 (Step 1301) . The 
operation information of each user ID is collected and 
25 stored in the service history storage table T21 (Step 
1302) . After the service history storage table T21 is 
compared with the service level contract content table 
T20 (Step 1303), it is checked whether the number of 



servers can be reduced from the viewpoint of the 
service level contract (Step 1304) . As a method of 
judging whether the number of servers can be reduced, a 
proportional calculation between products of CPU 
operation rates and the numbers of servers may be used. 
For example, although the service level condition of 
the user #0 has a CPU operation rate smaller than 50 %, 
if four Web servers are currently allocated and the CPU 
operation rate is all smaller than 25 %, then it can be 
judged from a simple proportional calculation that the 
number of Web servers can be reduced to two Web 
servers. In practice, the number of servers is 
multiplied by various safety coefficients given from 
experiences. If the number of servers can be reduced, 
a process termination instruction is notified to the 
server to be removed, via a corresponding one of the 
signal lines L100, L200 and L300. The notified server 
terminates the program process and releases the 
resource having been used. Namely, the contents of a 
memory address translation table and a cache are 
invalidated. After completion of the release, the 
server notifies the release completion to the 
management server. In response to this, the management 
server instructs the load allocating apparatus dlOO to 
d300 to change the server address correspondence tables 
T30 to T32. Next, it is checked whether the contents 
of all the load allocating apparatus are coincident. 
The charge calculation equation is changed. In this 



example, the number of allocated servers and the 
history of the allocated times are stored- For the 
charge calculation, a unit charge of one server per 
unit time is predetermined to calculate a charge. 
5 Namely, the total number of servers, the history of 
allocated times and the unit charge are multiplied 
together to calculate the charge (Step 1305) . 

In this example, since the allocation history 
is recorded distinguishably between the Web server 

10 group, AP server group and DB server group, the unit 
charge may be changed for each group to calculate the 
charge from a product of the number of allocated 
servers for each group, the history of the allocated 
times and each unit charge. In this example, although 

15 not shown, if the effective performance is different 
among servers, it is apparent to calculate the charge 
from a product of the number of servers, the effective 
performance, the history of the allocated times, and 
the unit charge. Also, in this example, the number of 

2 0 request packets passing through the gateway DO and the 
number of response packets are recorded. If the 
gateway passing throughput of request packets is 
relatively stable, the gateway passing throughput of 
response packets may be used as a criterion for 

25 estimating the data center process performance. In 

this case, the gateway passing throughput of response 
packets may be received from the gateway via the signal 
line L0 to calculate the charge through comparison with 



a predetermined contracted standard throughput. For 
example, the time during which the standard throughput 
is satisfied may be charged by a specified charge 
calculation, whereas for the time not satisfied the 
5 standard throughput, a penalty may be subtracted from 
the charge. By setting a unit charge for the standard 
throughput, the charge may be calculated from (measured 
throughput/standard throughput x unit charge) . If the 
input throughput of request packets fluctuates greatly, 
10 the charge may be calculated from (response packet 
throughput /request packet throughput) . 

Returning back to Fig. 8, it is checked 
whether it is necessary to increase the number of 
servers (Step 1306) . Checking how many servers are 
15 increased may be performed, for example, by a 

proportional calculation similar to reducing the number 
of servers. If it is necessary to increase the number 
of servers, by referring to the server allocation 
management table T22 12 for each of the Web server, AP 
20 server and DB server groups, it is checked whether 
there is an idle server (Step 1307) . If there is no 
idle server, this effect is notified to the system 
administrator (Step 1308) . If there is an idle server, 
a server to be allocated is selected (Step 1309) and 
25 the load allocating apparatus dlOO to d300 are 

instructed to change the contents of the server address 
correspondence tables T30 to T32 . After it is 
confirmed that the contents of all the load allocating 



apparatus are changed and are coincident, the charge 
calculation equation is changed (step 1310) . 

An example of the procedure by the control 
program P20 of the management server CO has been 
5 described above. It is apparent that the whole of the 
procedure is not necessarily required to be executed by 
the control program P20. For example, monitoring and 
collecting the operation information may not be 
performed by the control program P2 0 but the operation 

10 information may be received from another program. The 
contents of the processes at Step 1305 and Step 1310 
which the control program P20 executes essentially may 
be replaced by Step 1405A(B) and Step 1410A(B) shown in 
Figs. 9(A) and 9(B) in order not to change the charge 

15 information. Further, if each server has a function of 
not receiving a new user request after the process stop 
instruction, as shown in Fig. 9(A) Step 1305 and Step 
1310 may be replaced by Step 1405A and Step 1410A in 
order to instruct to change the server address 

2 0 correspondence tables T30 to T32 without waiting for 
completion of the process stop. 

In the above description, the volume access 
privilege table T33 of the storage resources is not 
changed. Even if the server allocation is changed, it 

25 is possible to prevent the volume without an access 
privilege from being accessed, because each program 
accesses the storage by adding the user ID. 

Next, a second embodiment of the invention 



will be described in which the data center is 
configured by using highly multiplexed SMP servers with 
a virtual computer function PRMF. 

The connection diagram for the data center 
5 and users is the same as that shown in Fig. 1. 

The data center shown in Fig. 10 has one Web 
server, one AP server and one DB server each having a 
virtual computer function PRMF. The internal 
structures of the AP server 1501 and DB server 1502 are 

10 the same as that of the Web server 1500, and so the 
description thereof is omitted. 

The user condition input dialog of the second 
embodiment is the same as that shown in Fig. 22. 
Namely, in this contract, only a user request packet 

15 having the source IP address of AO or Al is considered 
as the packet of the user company A. The IP addresses 
used by the user company A is alOO for the Web server, 
a200 for the AP server, and a300 for the DB server. 

Fig. 24 is an example of a service level 

20 contract condition input dialog. In this example, the 
contract with the A company indicates that the CPU 
allocation rate by the PRMF function of each of the Web 
server, AP server and DB server is controlled to be 
50 % or higher. 

25 Reverting to Fig 10, the Web server 1500 is 

constituted of a control unit 1503, an LPAR control 
register group 1504, CPU's 1505 and 1506, a memory 1507 
and network adapters alOO, blOO and ylOO. LPAR is the 



abbreviation of Logical PARtition (logical resource 
partition) . The LPAR control register group 1504 
stores information on a method of allocating resources 
to each OS. 

5 Fig. 11 shows an example of information 

stored in the LPAR control register group 1504. A 
conventional technology PRMF has information other than 
the user identifier UID field. LPAR# is an identifier 
uniquely assigned to each resource to be allocated to 

10 each OS. The network adapter is provided for each 

LPAR. A network adapter address is set to be identical 
to the IP address assigned to each user contracted by 
using the user condition input dialog. Therefore, a 
user request packet entering a network adapter is 

15 passed to a program running on OS of the corresponding 
LPAR. A memory allocation field stores information on 
which area of the memory 1507 is used by each LPAR. A 
CPU allocation % field stores information on at what 
ratio an OS belonging to each LPAR and a program on OS 

20 are operated on CPU's. The control unit 1503 refers to 
this information to control the operation ratio of 
LPAR • s . 

In this^ embodiment, the user identifier UID 
field is added which is made in one-to-one 
25 correspondence with LPAR. Under the PRMF control, 
different LPAR's cannot share resources so that 
securities between users can be guaranteed. 

Similar to the first embodiment, consider now 



that a user request is passed from the client aO, to 
the Web server alOO, AP server a200, DB server a300, AP 
server a200, Web server alOO, and back to client aO. 
The client aO generates a packet 1200 shown in Fig. 
5 12(A). The gateway AO generates a packet 1201 (Fig. 
12 (B) ) , and the gateway DO generates a packet 1202 
(Fig. 12(C)), similar to the first embodiment. 

The packet 1202 is passed via the signal line 
L0 to the network adapter alOO having the address alOO 

10 and to the application program on LPAR#0, i.e., an 
application program of the user A. This program 
generates a packet 1204 (Fig. 12(E)) having a 
destination address a200. Thereafter, in a similar 
manner, the packet is passed to an application program 

15 of the A company on the AP server 1501 and to the 

application program of the A company on the DB server 
1502. (Although not shown, the AP server 1501 has 
network adapters a200, b200 and y 200 corresponding to 
LPAR#0, #1 and #2. The LPAR#0 and #1 correspond to the 

20 user identifiers #0 and #1. This is also applied to 
the DB server 1502.) Similarly, the response from the 
DB server 1502 to the AP server 1501, Web server 1500 
and to client aO is performed by application programs 
on LPAR's assigned to the A company. Although the 

25 detailed description is not given, the above operations 
sequentially generate packets 1206 (Fig. 12(G)) to 1214 
(Fig. 12 (O) ) . 

Fig. 13 is a diagram showing the structure of 



the management server CO. T40 represents a LPAR 
allocation management table, and T19 represents a user 
ID table. T50 represents a service level contract 
content table for each user. In this contract, a CPU 
5 allocation rate of 50 % or higher is assigned to each 
LPAR of all of the Web server, AP server and DB server 
of the user having the user identifier #0. A CPU 
allocation rate of 20 % at a minimum is assigned for 
the user having the user identifier #1, an access 

10 response throughput from the data center is maintained 
30 transactions per second, and if there is a 
possibility that this throughput is not satisfied, the 
CPU allocation rate is increased. The control program 
P20 refers to the monitoring results and service level 

15 contract content table T50 acquired from the signal 
lines L100, L200, L300 and L0 to check whether the 
current resource allocation satisfies the service level 
contract, and stores the check results in the service 
history storage table T51. For example, the actual CPU 

20 use rate history of LPAR of the user identifier #0 is 
recorded. If the access response throughput of the 
user identifier #1 is lower than 30 transactions per 
second, the set CPU allocation rate is increased. To 
this end, the management server CO stores a CPU 

25 allocation management table T52 which stores 

information on what CPU allocation rate is set to which 
user. This table 52 stores the same contents as those 
in the CPU allocation rate field of the LPAR control 



register group of each of the Web server, AP server and 
DB server. The management of the charge information 
field of the service history storage table T51 is 
performed in the manner similar to the first 
5 embodiment. 

The procedure of the control program P20 to 
initially allocate resources in order to execute the 
above-described control will be described with 
reference to Fig. 21. 

10 The management server CO first acquires the 

information entered in the user condition input dialog 
shown in Fig. 22 to generate the user ID table T19 
(Step 2001) . Next, this information is set to the 
gateway DO via the signal line L0 (Step 2002) . 

15 The management server CO acquires the 

information entered in the service level condition 
input dialog shown in Fig. 24 to generate the service 
level contract content table T50 and the network 
adapter field in the LPAR allocation management table 

20 T40 (Step 2003) . 

Next, the service level contract content 
table T50 is referred to to confirm that a CPU 
allocation rate of 50 % at a minimum is assigned to 
the user identifier #0 and that a CPU allocation rate 

25 of 20 % is assigned to the user identifier #1. 

Thereafter, the CPU allocation fields of the CPU 
allocation management table T52 and LPAR allocation 
management table T40 are generated (Step 2004) . The 



contents of the LPAR allocation management table T4 are 
set to the LPAR control register group of the servers 
1500, 1501 and 1502 via the signal lines L100, L200 and 
L300 (Step 2005) . The service history storage table 
5 T21 is then generated in accordance with the service 
level contract content table T23 (Step 2006) . 

With the above operations, the management 
server CO prepares information necessary for the 
resource allocation control and sets the information to 

10 the gateway DO and the servers 1500, 1501 and 1502, so 
that the system can start its operation under the 
conditions of proper resource allocation. 

Next, the procedure of the control program 
P20 to change a resource allocation when the load 

15 increases will be described with reference to Fig. 14. 

Operation information monitoring (Step 1601) , 
operation information collection (Step 1602) and 
comparison with a service level contract (Step 1603) 
are similar to respective Steps 1301, 1302 and 1303 of 

20 the first embodiment shown in Fig. 8. It is thereafter 
checked whether the CPU allocation rate can be reduced 
(Step 1604) . If possible, the management server 
instructs to change the contents of the LPAR control 
resister group of the corresponding server. A method 

25 of checking whether the CPU allocation rate can be 

reduced is similar to the first embodiment. After the 
contents are changed, a charge calculation equation is 
changed (Step 1605) . In this example, histories of the 



CPU use rate and allocated time are recorded. A unit 
charge per unit time is predetermined for each of the 
Web server, AP server and DB server to charge a total 
of unit charges multiplied by CPU use rates. 
Obviously, the unit charge may be set differently to 
each of the Web server, AP server and DB server, or the 
unit charge may be set based upon an effective 
performance of each server. 

Next, it is checked whether it is necessary 
to increase the CPU allocation rate (Step 1606) . If it 
is necessary, it is checked whether the total of the 
CPU allocation rates set to the corresponding serve 
exceeds 100 % (Step 1607) . If exceeds, this effect is 
notified to the system administrator (Step 1608) . If 
not exceed, the management server instructs to change 
the contents of the LPAR control register group of the 
corresponding server, and after this change, the charge 
information is changed (Step 1609) . 

Lastly, a third embodiment will be described 
in which many and unidentified general consumers access 
home pages provided by A and B companies. 

A connection diagram between a data center 
and users is the same as that shown in Fig. 1. General 
users are clients cO and cl. 

Fig. 15 shows the structure of a data center. 
Similar to the first embodiment, a load allocating 
apparatus dlOO can distribute loads to a plurality of 
servers. For the purposes of description simplicity, 



only Web servers are used. All the Web servers share a 
storage S4 via a signal line L120. The storage S4 
stores files FO and Fl, the file FO storing information 
including home page information of the A company and 
5 the file Fl storing information including home page 
information of the B company. The home page 
information has a tree structure so that each 
information can be sequentially accessed from a root 
■ page. It is assumed that the address for accessing the 

10 home page of the A company is alOO and that for the B 
company is blOO. 

Fig. 25 shows an example of an input dialog 
to be used for a contract between the A company and the 
data center to determine the condition of general users 

15 accessing the home page. In this example, the contents 
of this contract are as follows. As the access 
destination IP address of an access request packet 
input to the gateway DO, alOO is used in order to 
identify that the access to the home page of the A 

20 company is an access request from a user group 

belonging to the A company. In addition, the A company 
uses alOO as the IP address for creating a home page. 

The client cO generates a packet 1700 shown 
in Fig. 16(A) in order to access the home page of the A 

25 company. The gateway 1700 has a user ID table T60 

shown in Fig. 17. Since the destination address of the 
packet 1700 is alOO, the gateway can know that the 
packet is to be accessed to the home page of the user 



identifier #0, and generates a packet 1702 shown in 
Fig. 16(C). Thereafter, the load allocating apparatus 
dlOO sends this access request to either a Web server 
alO or all. In this example, the server alO is 
5 selected. A packet 1703 is therefore generated (Fig. 
16(D). Similarly, the load allocating apparatus dlOO 
changes the packet to a packet 1712 (Fig. 16 (M) ) as a 
response packet which is changed to a packet 1714 (Fig. 
16(0)) by the gateway DO and returned to the client cO. 

10 The internal structure of the management 

server CO is shown in Fig. 18. The structure is the 
same as that shown in Fig. 4, excepting that a root 
file management table T70 is added.' This table T70 
stores the file name of a root page of the home page 

15 for each user identifier. 

The procedure of the control program P20 to 
be executed when the load increases is illustrated in 
Fig. 19. This procedure is the same as that shown in 
Fig. 8, excepting that Step 1310 shown in Fig. 8 is 

20 replaced by Step 1800. Only Step 1800 different from 
that shown in Fig. 8 will be described. After a server 
is selected at Step 1309, the root file management 
table T70 is referred to at Step 1800 to instruct the 
selected server to register the root file name 

25 corresponding to the user identifier. Thereafter, 
similar to Step 1310 shown in Fig. 8, the load 
allocating apparatus dlOO is instructed to change the 
server address correspondence table T30. After the 



- 34 - 

completion of this change, the charge information is 
changed. A newly selected server has initially a 
standard root file name and changes (registers) the 
root file name to thereby enable to access the correct 
5 home page . 



